Shape Up: Stop Running in Circles and Ship Work that Matters

チームの働き方は、チームによってなし得ることに影響がある

間違った方法でやるとめちゃくちゃになる

付箋を壁に並べたりもしないし、デイリーミーティングやデザインスプリント、開発スプリントもない

バックログやベロシティなどもない

本書は、Basecamp の仕事のやり方を伝えるもの

主要な考えは次の通り

6 週間サイクル

意味のある単位での開発を最初から最後までやり切れる長さであり、時間の無さを最初から感じられる長さ

チームに仕事を渡す前に shaping する (shape the work) : 輪郭を描くとか、そういうイメージ

サイクルチーム (the cycle team) と小さなシニアグループが並行して作業

プロジェクトが賭けるに値するかどうかを判断する前に、シニアグループが解決策の重要な要素を定義する

チームが何をすべきかわかる程度には具体的ではあるが、詳細を自分たちで決められる程度には抽象的

見積もりより意欲 (appetite) に焦点を当てる

チームに責任を持たせる

リスクに目標を定める

本書で説明するプロセスでは、常に、出荷できないリスクに目標を定めている

本書の構成

Part 1 : Shaping について (プロジェクトのスケジュールを立てる前にやるべき事前作業)

Part 2 : 賭けについて (提案されたプロジェクトの中から何を実行するか、何をやるか)

Part 3 : 構築について (チームに期待することと、チームが何をすべきかを発見する特別なプラクティス)

付録

Part 1 : Shaping

仕事を shaping していく (Shape the work) 際には、適切な抽象度にしていく

ワイヤーフレームは具体的すぎる

簡単な言葉だけでは曖昧すぎる

ケーススタディ : ドットグリッドカレンダー

カレンダーは難しいので、6 週間では多くの機能をもつカレンダーはできない → ユースケースを絞り込む

定義にあたって重要な要素

1. 荒い : 未完成であることがわかるラフさ。 細かな部分は決まっていない

2. 解決する : マクロレベルでは解決策の主要な要素が揃っている

3. 境界がある : チームが何をしないかを明確にしている

誰が shaping するか？

インターフェイスのアイデアと技術的な可能性をビジネスの優先順位と組み合わせて考える必要

ジェネラリストとして 1 人でやるか、2、3 人と協働するか

shaping と構築 (builing) のための 2 つのトラックを用意する

定義は不確実性が高く、スケジュールを立てることが難しいため

6 週間のサイクルの間に、チームは定義された (shaped) 仕事にあたり、定義者 (shapers) は将来チームが取り組む可能性があるものに取り組む

定義作業は、それに賭けることが決まるまで非公開 : うまくいかないときに棚に置いたりドロップしたりしやすい

shaping の手順 (詳しくは後続の章で説明)

1. 境界を設定 : 生のアイデアにどれだけの時間をかける価値があるか、問題をどう定義するか、を見出す

2. 要素を素描 : 解決策をスケッチするという独創的な作業

素早く動き、広い可能性を探るため、ワイヤーフレームよりも高いレベルの抽象度で実施

成果物は、意欲 (appetite) の範囲内で問題を解決するアイデア (詳細は未定)

3. リスクと落とし穴 (rabbit holes) に対処

チームをつまずかせる可能性のある穴や未回答の質問を見つける

チームが行き詰まったり時間を無駄にしたりしないように

4. ピッチを記述

賭ける可能性のある形になったら、ピッチと呼ばれる正式な文書にパッケージ化

ピッチは、問題、制約、解決策、落とし穴、および制限を要約

意欲 (appetite) の設定

意欲 (appetite) = 時間予算、というふうに捉える

生のアイデアにどれだけの時間をかける価値があるか、どれだけ注意を払うべきかを明確にする

2 つのサイズで意欲 (appetite) を捉える

小さなバッチ : デザイナー 1 人とプログラマー 1, 2 人が 1, 2 週間で作り上げる

大きなバッチ : 同じ規模のメンバーで 6 週間かけて作る

「固定時間、可変スコープ」 (fixed time, variable scope) の原則で考える

意欲 (appetite) は見積りとは全く別物 (見積りは設計をもとに数字を出すが、意欲 (appetite) は数字を元に設計していく)

創造的な設計プロセスにおける制約条件

「良い」 かどうかの判断は相対的 : どれだけ時間をかけるか、どれだけ重要か、という文脈から判断する必要がある

生のアイデアには、「面白いね、いつかやるかも」 というソフトな NO の反応をすべき

理解していないものを否定してはいけないが、全てを受け入れる時間的余裕もない

意欲 (appetite) の設定に加えて、何が問題なのかを絞り込む必要がある

顧客が何か求めてきたときに、その要求がなぜ発生したのかを辿ることで、より良い別の解決策を見出せる可能性がある

カレンダーの例

カレンダーの機能を全部網羅することは難しいが、特定のユースケースに絞ることで 6 週間サイクルで開発できる大きさに解決策を絞り込むことができる

福袋 (たくさん詰まったもの) に注意する

単一の問題に紐づかない 「再設計」 や 「リファクタリング」 などは不明瞭で良くない

何を意味していて、どこから始まって、どこで終わるのかがわからない

生のアイデアと意欲と絞り込まれた問題定義が揃ったら次の段階へ

意欲 (appetite) と解くべき問題が決まったので、解決策としての要素を決めていく

注意点

適切な人と (あるいは一人で) 作業する

詳細に立ち入りすぎない

決めること

システムのどこに新しい要素を入れるのか

どうやってその変更をするか

重要な部品や相互作用は何か

それがどう動くか

これらの手法を使うことで、適切な抽象度で表現できる

プロトタイピングで出てきた要素がアウトプットになる

この後はストレステストやリスク低減を行う

決められた時間枠に収まる仕事を shape していることを忘れないように

落とし穴はできるだけ事前につぶしておく

解決策の要素の具体化は素早く実施したが、ここでは速度を落として思いついたものを批判的に調べる

解決済みだと考えている各部の実行可能性についても検討

これまでやったことがない技術的な作業をするか？ 部品の組み合わせ方の仮説はある？ チームがはまらないように事前に解決しておくべきことはある？

何がスコープの範囲外かを共有する

思いついていた機能のうち、不要なものは減らす

完全に確認を持てないいくつかの場所について、専門家から意見をもらうなど

「これは可能ですか？」 ではなく、「これは 6 週間で可能ですか」 と聞く

他の人も理解できるようにピッチ (pitch) を書く

ピッチの目的は、良い可能性のある賭け (good potential bet) を書くこと (基本的にはプレゼンテーション)

ピッチに含める 5 つの要素

問題 (Problem) : 生のアイデア、ユースケース、またはこれに取り組む動機

意欲 (Appetite) : どれだけの時間を費やしたいか、そしてそれがソリューションをどのように制約するか

解決策 (Solution)

落とし穴 (Rabbit Holes) : 問題回避のために試す価値のある解決策の詳細

やらないこと (No-gos) : コンセプトから特に除外されているもの

要素を決めていくフェーズでは高い抽象度で作業していたが、ピッチを書く際には他の人でも理解できる程度には詳細を描く必要がある (とはいえ高い抽象度で)

例

ただし、必要以上に UI デザイナーが縛られないように、どこまで自由に設計できるかを明記する

ピッチの提示

基本的には非同期で、関係者が読めるように

場合によってはリアルタイムでピッチのプレゼンを行う

読者は、穴を突いたり不足している情報を埋めたりといった貢献をするため、コメントする

Part 2 : Betting

重要なアイデアは復活するので、重要でないアイデアで管理コストが増えることを防ぐ

6 週間サイクルの前に、サイクルで何をするかステークホルダーが決める : betting table

過去 6 週間のピッチと、誰かが復活させたピッチが対象

賭ける (bet) ことにした場合、次のサイクルで開発される

さもなければ捨てられる (公式的には管理されない)

復活させたい人は、独自の方法で追跡し、また次回復活させることができる

6 週サイクルの理由

2 週間サイクルだと短すぎて意味のあることが成し遂げられないし、計画のオーバーヘッドが大きい

6 週サイクルを続けると次のことを考える余裕がないので、サイクルごとに 2 週間の冷却期間 (cool-down の期間) を置いている

チームはデザイナー 1 人とプログラマー 1, 2 人が標準的

Betting table は冷却期間に実施される会議

CEO、CTO、シニアプログラマー、製品ストラテジストが参加

アウトプットは次のサイクルの計画

短い時間でシュッと決める

なぜ 「賭け」 (bet) なのか

ひとつは、賭けというのは、支払いがあるということ

計画として単にタイムボックスを埋めるだけでなく、明確なアウトプットに対してやるかどうかの判断をする

賭けには約束がある

賭けたものには、途中で中断することなく 6 週間専念してもらう

チームは 6 週でリリースする必要がある

「たった 1 時間」 とか 「たった 1 日」 でも、他チームを助けるなど他の割り込みがあると、勢いが削がれてしまう

賢い賭けには、失うものに上限がある

この場合、失うのは最大で 6 週間という時間

6 週でリリースできなければ期間の延長は原則としてない

良い効果

プロジェクトの暴走を止める

shaping に問題があったということなので、間違ったアプローチにそれ以上時間をかけない

チームの、プロジェクトに対するオーナーシップの強化

バグがあっても？

バグでも、よほどの重大なものでなければ、6 週待ったり、修正しないということが可能

バグ対応どうするか

冷却期間 (cool-down) で行う

賭けに提案する

年に 1 回のバグスマッシュ (bug smash) を使う : バグ修正のみのサイクル

賭けにあたって、新製品の場合は通常フローとは別のやり方が必要

3 つのフェーズ

シニアグループのみで行う

生産 (Production) モード : 既存製品の場合に近い形で、shaping して bet する

まだリリースされていないのでマージはするが一般公開はされない

浄化 (Cleanup) モード : リリース前の綺麗にする作業

Shaping はなくて、バグスマッシュみたいな感じ

Part 3 : Building

チームがプロジェクト全体を引き受けるように、タスクではなくプロジェクトに人をアサインする

完了は、デプロイを意味する (= QA などもサイクル内で終える必要がある)

ドキュメント更新などは必ずしもサイクル内に終えなくても良い (それらは完了しないリスクが低く、別チームが担うことも多い)

プロジェクトにチームが追加された後に最初にやることはキックオフ

元のピッチ (か、蒸留版のピッチ) をチームに共有

キックオフミーティングを開催して不明点を解消

キックオフ後のしばらくは、各自がそれぞれ調査等を行う (長くて 3 日程度)

状況に変化がないように見えるが、このフェーズを尊重しなければならない

最初は想定されたタスクのみがあるが、プロジェクトを進めて実際に手を動かす中で新しいタスクが見えてくる

何らかの動くものを早期に (1 週間程度で) 作ることを目指す

そのために、レイヤーごとに水平に考えるのではなく、垂直に考える必要がある

プロジェクト内の他チームの作業をプログラマが待つ必要はないはず (必要な情報はピッチにあるはず)

最初に何を構築すべきか？

コアなもので、小さいもの

そういうものが複数ある場合は、より斬新なもの

作業を人や役割毎に整理するのではなく、プロジェクトの構造で整理する

プロジェクトというひとつのスコープを、独立して作業できる複数のスコープに分割する

スコープは、プロジェクトレベルで語彙になる

スコープが適切な印

スコープたちがプロジェクト全体を表しており、隠れた細部を気にするような心配がない

スコープが提供する語彙により、会話が円滑になる

新しく発生したタスクをどこに置けばよいかわかる

スコープに収まらない場合もあるので、それは 「チャウダー」 として扱う (ただしできるだけそういうものはなくす)

タスクを進めるにしたがってプロジェクトのタスクリストにタスクが追加される → ある時点のタスクリストを見ても進捗状況はわからない

プロジェクト状況を把握するために、「完了/未完了」 という考えから 「未知/解決済み」 という考えに移行する

作業の 2 フェーズ : 丘に登って下りる

自分たちのアプローチと何をやっていくかを理解する段階 (丘を登る)

不確実、未知、問題解決に満ちている

実際に実行する段階 (丘を下る)

確実、自信、全てを見通し、何をすべきかわかっている、ということに特徴づけられる

プロジェクトのスコープごとに、丘のどの位置にいるかをプロットすることで、状況を表現できる

マネジャーはそれを見て状況を確認できる

状況変化を追うことで、困っているスコープがどれかなどがわかる

ちなみに、動いていないスコープでも困ってないことはある (大きすぎて動きが見えないだけ) → スコープを分割する

丘の頂上についたとみなせるのは、頭で考えるだけではなく実際に手を動かしてアプローチを検証して、そのアプローチで問題ない (他に未知のものはない) と自信をもって言えるようになったとき

問題解決も同様に、重要なものから進める

理想を追求していては完成することはない

理想と比較するのではなく、ベースライン (顧客の現状) と比較する

6 週間の制限があるので、積極的にトレードオフすること

スコープは自然と大きくなるものなので、チームに権限やツール、責任を与えて絶えずスコープを削減していく

基本的な品質はプログラマーとデザイナーが責任を負うため

QA は 「あると良い」 機能を提案するので、チームはその中か一部を 「必須の」 機能にして実装したりする

QA はゲートやチェックポイントではなく、レベルアップのためのもの

プロジェクトの延長

真に絶対必要な機能が未実装で、いずれの残作業も作業の下りフェーズ (あとは実行するだけ) である場合に、延長を検討することがある

基本的には 2 週間の冷却期間があれば十分

延長が習慣化するとチームのパフォーマンスに悪影響なので、規律を守る

リリース後にユーザーから反対意見が出ることがある

簡単に屈しないように : それが収まるのを数日待つ

何のための変更か、誰を助ける変更なのか、という点に立ち返る

ユーザーからのフィードバックは生のアイデアなので、重要なのであれば shaping して対応していく

重要な概念

Shaping された仕事 (Shaped work) とそうでない仕事

適切な抽象化レベルでの設計

ブレッドボードとファットマーカーのスケッチで概念化

失うものの上限がある状態 (サーキットブレイカー) で賭けをして、作業期間中の割り込みをなくしてそれらを尊重

適切なサイクル期間 (6 週間)

サイクル間の冷却期間

プロジェクトをスコープに分割

作業における上り坂と下り坂、そして未知のことについてのコミュニケーション

必須のものとあると良いものを分離するためのスコープハンマー

Appendicies

Shaping

Shaping のための Basecamp チームを作る (「Product Strategy」 などの名前で)

このチームには、Shaping を行う人とピッチにフィードバックする人、それから賭けをする人を入れる

メッセージボードにメッセージとしてピッチを投稿するなどして shaping フェーズを実施

サイクルプロジェクト

6 週サイクルのそれぞれのプロジェクトのために Basecamp プロジェクトを作る

そのプロジェクトにかかわるプログラマーとデザイナーを追加

Post a kick-off message to the Message Board with the pitch or a restatement of the shaped work for the team’s reference.

スコープごとに To-Do リストを作成

ヒルチャートでスコープを追跡

Shape Up 手法の中で特に重要な考え (Basic truths)

正しい仕事がなんであるかを見出す仕事が必要 (これが shaping) : 明確な境界と期待の設定

何に賭けるのかと、失うものの上限を設けること

作業を未知のものと既知のものに分けて、先に重要で不確実なものから進めて後から増える未知のものの容量を確保

実践面は組織規模などによって変わる

2, 3 人程度であれば、Shape Up 手法のような構造化は必要なく、流動的 (ひとりが複数の役割をこなす必要)

人が増えると役割を専門化させて構造化する方が良くなる

選択子 A : 6 週間の実験を 1 回やってみる

プログラマーとデザイナーのチームで、事前に輪郭を描いた仕事を定義して、詳細はチームに考えてもらうという形で、途切れない期間で仕事を進めてもらう

選択子 B : Shaping からはじめる

6 週間の時間を確保することが難しいなら、まずはこっちから

選択子 C : 6 週間サイクル

2 週間などの短いサイクルで作業しているチームであれば、まずはサイクルを伸ばしてオーバーヘッドを下げる

研究や発見の改善よりも、まずはデリバリー能力の強化から (いい案を考えてもリリースできなければ意味がない)

途中の状況を把握できないことを心配せずに、結果に焦点を当てる